Using a platform specific sub-struct with either HANDLE or int would clean up this logic as well.
Platform specific logic will be encapsulated within the sub-struct definition.
However, we must take care that we maintain client side backwards compatibility.

This is handled opaquely now through use of a void pointer, as discussed, and is used to initialize the appropriate type when creating the substruct. None of the client APIs needed modifications in our L0_shared_memory test, which gives me confidence that we did not break backwards compatibility with this change. Please let me know if you have other concerns.

Should we add an else block catching unsupported platform flags?

The platform flag is currently passed in from build_wheel.py, so, from our perspective, the possible platforms are all handled. If the platform does not contain the substring "linux" or is not "win_amd64", it will be "any". In this case, we do not include either shared library object.

Are you suggesting raising an error in the event the setup.py script is called independently? Like so:

if "linux" in PLATFORM_FLAG:
    platform_package_data += ["libcshm.so"]
elif PLATFORM_FLAG == "win_amd64":
    platform_package_data += ["cshm.dll"]
elif PLATFORM_FLAG != "any":
    raise Exception(f"Unsupported platform flag \"{PLATFORM_FLAG}\" specified.")